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Remarks/Arguments: 

Claims 2-1 1 are pending in the present application, of which claims 6-11 are added. In the 
Office Action dated April 21, 2005, the Examiner has again rejected claims 1-3 and again 
allowed claims 4-5. Claim 1 is canceled, and claims 2-3 are rewritten in independent form. 

Claims 6-11 are added herein, and draw support from the written description at page 4, lines 
21-24 (as to mobile station and processor) and page 5., lines 7-10 (as to embodied computer 
program), and claim 5 (as to network element). The elements of new independent claim 6 
mirror those of amended claim 2, but for a computer program product. The elements of new 
independent claim 9 mirror those of amended claim 3, also for a computer program product. 

Claims 2-3 were rejected as obvious over Lannen in view of Hughes, The Office Action cites 
to Lannen for portions of claim 1 (now within amended claims 2-3) and admits that Lannen 
fails to specifically disclose a hexadecimal check digit calculation procedure. The Office 
Action recites that "such a hexadecimal check digit calculation procedure is well known in 
the art, as taught by Hughes et al. (col. 1 1/ln. 53-col. 12/ln. 43." But claims 2-3 are not made 
obvious by any generic hexadecimal check digit calculation procedure. Claim 2 explicitly 
recites that "hexadecimal digits A, B, C, D, E and F are first converted to decimal digits 10, 
11, 12, 13, 14 and 15, respectively,..." Claim 3 explicitly recites that "the check digit 
calculation procedure uses base 16 for all calculations to derive a base 16 check digit." 
Hughes does neither. 

Specifically, Hughes teaches at col. 1 1 line 53 to col, 12 line 43 that the sum of the decimal 
figures (base 10) of the digit field of Figure 9 (0+2+7+2+8+0+8+1=28) is converted to a 
hexadecimal value (base 16), and the checksum byte 202 is that value needed to drive the 
remainder of the hexadecimal value to zero [28/16=1 remainder 12, the checksum byte is 4 
because 1 remainder 12+4(the value of the checksum byte)=2 remainder 0 in base 16). 
Clearly, Hughes does not convert hexadecimal digits A, B, C, D, E and F to decimal digits 
10, 11, 12, 13, 14 and 15, respectively as in claim 2, but rather calculates a base 16 value that 
when added to the hexadecimal remainder will drive the base 16 value to zero. Any other 
value of the checksum byte will yield an invalid flag (see col. 12, lines 33-36: "If the sum is 
not equal to 0 modulo 16, the non-valid flag 224 is set."). The remainder 12 of Hughes' 
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example is not converted to a decimal digit but remains in base 16 in order to find the value 
to add to the modulo 16 remainder in order to arrive at 0 modulo 16, no remainder. 

The fact that the text of Hughes uses the term "12" rather than "C" is a construct of readers 
being most familiar with base 10 terminology; the text of Hughes is clear that the "remainder 
12" remains a modulo 16 digit, because the checksum byte 202 is determined specifically to 
yield 0 modulo 16 when added to that remainder. If the remainder were decimal, the 
necessary result would be that Hughes adds a decimal value (e.g., the remainder as 
improperly characterized as two decimal digits) with a hexadecimal value (the checksum 
byte), an operation that is generally not conducive to a coherent mathematical system, and 
clearly not evident in Hughes. Hughes therefore arrives at a checksum byte without 
converting hexadecimal digits to decimal digits as recited in claim 2. 

Additionally, claims 2 and 3 each recite an IMEI code having at least a six digit hexadecimal 
serial number representation used with a hexadecimal check digit calculation procedure. In 
contradistinction, Hughes clearly begins with a decimal phone number (col. 11, line 45 and 
Figure 9), sums it, and converts that sum to hexadecimal in order to determine the checksum 
byte 202. There is no hexadecimal serial number representation in Hughes from which a 
hexadecimal check digit is derived, as recited in each of claims 2 and 3. 

Further to the above, claim 3 recites using base 16 for all calculations to derive a base 16 
check digit. Because the original Hughes phone number uses decimal digits, the summing 
operation that is used in determining the Hughes checksum byte is a decimal operation (col. 
12, line 68: 0+2+7+2+8+0+8-1-1=28), so base 16 is not used in all calculations of the check 
digit calculation procedure as recited in claim 3. 

The Office Action admits that Lannen fails to teach or suggest a hexadecimal check digit 
calculation procedure. The above remarks show that Hughes clearly fails to teach or suggest 
the check digit calculation procedures as separately recited in claims 2 and 3, so the 
combination of references fails to make obvious either of claims 2 or 3. Claim 6 recites 
similarly in relevant part to claim 2, and claim 9 recites similarly in relevant part to claim 3, 
and should be patentable for the same reasons recited above with respect to claims 2 and 3. 



6 



AppL No. 09/783,917 

Amdt. Dated July 18, 2005 

Reply to Office Action of April 21 , 2005 

The Applicant respectfully requests that the Examiner pass each of claims 2-11 to issue. The 
undersigned representative welcomes the opportunity to resolve any matters that may remain, 
fomial or otherwise, via teleconference at the Examiner's discretion. 

Respectfully submitted: 
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